Bug 1156592 added a probe to measure tab switch times in e10s. We have two probes to measure tab switching in non-e10s. One of them measures only part of the tab switch and the other (FX_TAB_SWITCH_TOTAL_MS) is broken as I explained in bug 1157423 comment 0. We'd like to be able to make a fair comparison between e10s and non-e10s. Vladan, could someone on your team look into this?

We'd love to help with this but the perf team is pretty busy with Telemetry unification, the Content Performance program, and perf fixes in Q2. Avi could share what he knows about measuring tab switches, but I don't think we'll have time to implement this measurement in the next month

Yes, if avih could do a braindump here, I think we could try to lay out our probes correctly to get a fair comparison.

Talking with avih, he didn't actually write the FX_TAB_SWITCH_TOTAL_MS probe. That was jrmuizel in https://hg.mozilla.org/mozilla-central/rev/155f7491ad68 for bug 800031. Jeff - how should we measure tab switch times in single-process Firefox with OMTC enabled? How do we lay out our probes for that?

So I talked to jrmuizel and mstange about this IRL. Here's what they suggest: For the multi-process case, they suggest that we modify our "end" probe by waiting for the first MozAfterPaint after MozLayerTreeReady is fired before stopping the stopwatch. For the single-process case, they suggest that we record the timestamp on the click event to switch the tabs, and then take the delta between that and time time of the next MozAfterPaint event (we might want to add compositing time to MozAfterPaint). Note also that mstange found this comment: https://bugzilla.mozilla.org/show_bug.cgi?id=1026806#c0 Which suggests that we might need to beef up how we do timestamps on events in Gecko.

(In reply to Mike Conley (:mconley) - Needinfo me! from comment #4) > So I talked to jrmuizel and mstange about this IRL. Here's what they suggest: > > For the multi-process case, they suggest that we modify our "end" probe by > waiting for the first MozAfterPaint after MozLayerTreeReady is fired before > stopping the stopwatch. Jim's patch does that, so we just need to fix the single-process case.